The overall goal of the team project was to provide us with experience in developing a relatively large software system as part of a team. Broadly speaking, this goal has been achieved. We have expanded our interpersonal skills, and developed a better understanding of team dynamics within a software engineering context.

From an organisational perspective, we felt that the laissez-faire structure was not the best choice. It is clear from our schedules, detailed in appendix B.2, that slippages occurred on both the design and implementation schedules. It is our belief that these slippages could have been managed better with greater leadership from the beginning.

In general, our team meetings, beyond our weekly supervisor meetings, lacked structure and focus. This inevitably led to poor attendance; something which was not resolved properly, again, due to a lack of well-defined leadership. Our meetings should have been more structured, including a defined agenda and the taking of minutes.

We made use of instant messaging services to communicate, and this may have contributed further to our lack of organisation. Working together in person adds structure and discipline. 

In general, our use of Subversion was good. However, there were some issues with team members committing non-functional code. This is bad practice, and slows down the development process. While this was highlighted, better defined leadership would have resolved the issue more promptly.

To summarise the organisational issues, we may have been apprehensive to define a clear leadership hierarchy, given that this was our first project of this type. In choosing the laissez-faire ``structure'', we were able to avoid the potential conflict associated with well-defined leadership. This was to the detriment of the project's progression.

Beyond the organisational issues, we exploited the natural divide within the client-server architecture adopted for the project. This meant that, as detailed in appendix B.1, the team was allocated to work on either the client or the server section. We allocated this with three people working on the client, and two on the server.

This natural divide, while relatively successful, may not have been the best one. It required three people (two on the server, one on the client) to have knowledge of how the protocol worked, and how to implement this. If the division had been on network code versus UI code, then perhaps only two people would be responsible for implementing the network code across both the client and server.

We did not foresee the length of time required to integrate the client network code and client GUI. This time required far exceeded that which had been allocated for the task, and this combined with the organisational issues above, led to less coverage of our requirements.

This issue could have been resolved by either working more closely together from the beginning, or better defining the boundaries between the blocks of work we were each completing. This could have been performed using software engineering practices, such as facades, so that the team knew what inputs and outputs were expected from their own parts of the system.

In summary, we feel that the project has been successful in exposing the good and bad of working as part of a team. Team organisation is more difficult than we anticipated, but as a result, we are clear on what we would do differently to improve. We are frustrated that only a small number of requirements have been implemented, but hopefully those which have not been implemented will form the basis of future work.
